home *** CD-ROM | disk | FTP | other *** search
/ Developer Helper 1: Phil & Dave's Excellent CD / Excellent CD HFS.raw / Moof / Goodies / DTS Goodies / Obfuscated_C / README next >
Text File  |  1989-04-13  |  8KB  |  194 lines
  1.                The International Obfuscated C Code Contest
  2.  
  3.  
  4. Obfuscate:  tr.v.  -cated, -cating, -cates.  1. a.  To render obscure.
  5.         b.  To darken.  2. To confuse:  His emotions obfuscated his
  6.         judgement.  [LLat. obfuscare, to darken : ob(intensive) +
  7.         Lat. fuscare, to darken < fuscus, dark.] -obfuscation n.
  8.         obfuscatory adj.
  9.  
  10.  
  11.  
  12. How it was started:
  13.  
  14. The original inspiration of the International Obfuscated C Code
  15. Contest came from the Bourne Shell source and the finger command as
  16. distributed in 4.2BSD.  If this is what could result from what some
  17. people claim is reasonable programming practice, then to what depths
  18. might quality sink if people really tried to write poor code?
  19.  
  20. I put that question to the USENET news groups net.lang.c and
  21. net.unix-wizards in the form of a contest.  I selected a form similar
  22. to the contest (Bulwer-Lytton) that asks people to create the worst
  23. opening line to a novel.  (that contest in turn was inspired by disgust
  24. over a novel that opened with the line "It was a dark and stormy
  25. night.")  The rules were simple: write, in 512 bytes or less, the worst
  26. complete C program.
  27.  
  28. Thru the contest I have tried to instill two things in people.  First
  29. is a disgust for poor coding style.  Second was the notion of just how
  30. much utility is lost when a program is written in an unstructured
  31. fashion.  Contest winners help do this by what I call satirical
  32. programming.  To see why, observe one of the definitions of satire:
  33.  
  34.     Keen or energetic activity of the mind used for the purpose 
  35.     of exposing and discrediting vice or folly.
  36.  
  37. The authors of the winning entries placed a great deal of thought into
  38. their programs.  These programs in turn exposed and discredited what I
  39. considered to be the programmer's equivalent of "vice or folly".
  40.  
  41. There were two unexpected benefits that came from the contest winners.
  42. First was an educational value to the programs.  To understand these C
  43. programs is to understand subtle points of the C programming language.
  44. The second benefit is the entertainment value, which should become
  45. evident as you read further!
  46.  
  47.  
  48.  
  49. Suggestions on how to understand the winning entries:
  50.  
  51. You are strongly urged to try to determine what each program will
  52. produce by visual inspection.  Often this is an impossible task, but
  53. the difficulty that you encounter should give you more appreciation
  54. for the entry.
  55.  
  56. If you have the energy to type in the text, or if you have access to
  57. a machine readable version of these programs, you should next consider
  58. some preprocessing such as:
  59.  
  60.     sed -e '/^#.*include/d' program.c | cc -E
  61.  
  62. This strips away comments and expands the program's macros without
  63. having things such as <stdio.h> macros clutter up the output.  If the
  64. entry requires or suggests the use of compile line options (such as
  65. -Dindex=strchr) they should be added after the '-E' flag.
  66.  
  67. The next stage towards understanding is to use a C beautifier or C
  68. indenting program on the source.  Be warned that a number of these
  69. entries are so twisted that such tools may abort or become very
  70. confused.  You may need to help out by doing some initial formatting
  71. with an editor.  You might also try renaming variables and labels to
  72. give more meaningful names.
  73.  
  74. Now try linting the program.  You may be surprised at how little lint
  75. complains about these programs.  Pay careful attention to messages
  76. about unused variables, wrong types, pointer conversions, etc.  But be
  77. careful, some lints produce incorrect error messages or even abort!
  78. Your lint may detect syntax errors in the source.  See the next
  79. paragraph for suggestions on how to deal with this.
  80.  
  81. When you get to the stage where you are ready to compile the program
  82. examine the compilation comments above each entry.  A simple define or
  83. edit may be required due to differing semantics between operating
  84. systems.  If you are able to successfully compile the program,
  85. experiment with it by giving it different arguments or input.
  86. You may also use the makefile provided to compile the program.
  87. Keep in mind that C compilers often have bugs, or features which
  88. result the program failing to compile.  You may have to do some
  89. syntax changing as we did to get old programs to compile on strict
  90. ANSI C compilers.
  91.  
  92. Last, read the judges' comments/spoilers on the program.  Hints
  93. for `foo.c' are given in `foo.hint'.  Often they will contain suggested
  94. arguments or recommended data to use.
  95.  
  96. If you do gain some understanding of how a program works, go back to
  97. the source and reexamine it using some of the techniques outlined above.
  98. See if you can convince yourself of why the program does what it does.
  99.  
  100.  
  101.  
  102. About the judges:
  103.  
  104. As of 1988 the contest had two judges: Landon Curt Noll (contest
  105. founder) and Larry Bassel (judge since 1985).  Landon works as a
  106. systems programmer for Amdahl Corporation and Larry works as an systems
  107. programmer for Sun Microsystems.  In real life, both judges strongly
  108. dislike obfuscated code.
  109.  
  110.  
  111.  
  112. Regarding the source archive:
  113.  
  114. Each sub-directory contains all the entries for a single year.  Often
  115. the file names match one of the last names of the author.  Judges'
  116. hints are given in files of the form ``*.hint''.  The makefiles
  117. given are set up for a System V based machine.  You may need to
  118. tweak this makefile to get everything to compile correctly.
  119. Read the hint files for suggestions.  The rules for a given
  120. year are given in the file named ``rules''.  The last year
  121. in an archive contains a copy of the rules for the upcoming
  122. contest.
  123.  
  124.  
  125.  
  126. Regarding the distribution of sources:
  127.  
  128. All contest results are in the public domain.  We do ask that you observe 
  129. the following request:
  130.  
  131. You may shar these files with others, but please do not prevent them of
  132. doing the same.  If some of these files and/or contest entries are
  133. published in printed form, or if you use them in a business or classroom
  134. setting, please let us know.  We ask that you drop a line to the
  135. 'judges' Email box.  As of 1988, it is:
  136.  
  137.     judges@uts.amdahl.com    -or-    amdahl!judges
  138.  
  139.     [this could change from year to year, so consult the current rules]
  140.  
  141.  
  142.  
  143. Some final things to remember:
  144.  
  145. While the idea for the contests has remained the same through the
  146. years, the contest rules and guidelines vary.  What was novel one year
  147. may be considered common the next.  The categories for awards differ
  148. because they are determined after the judges examine all of the
  149. entries.
  150.  
  151. The judges' hints assume that the program resides in a file with the
  152. same username as the author.  Where there is more than one author, the
  153. first named author is used.
  154.  
  155. Some C compilers are unable to compile some of these programs.  The
  156. judges tried to select programs that were widely portable and
  157. compilable, but did not always succeed.  As of 1988, only ``K&R''
  158. compilers were used.  Due to the timing of the ANSI C standard, ANSI C
  159. issues were not addressed until 1988 at all (and in 1988 there were
  160. just a few comments in the hint files).  Often only a simple edit is
  161. needed to get a new C compiler to accept the source file.
  162.  
  163. The contest rules are posted in early March.  The winners are announced
  164. at the Usenet BOF of the Summer Usenix conference.  Later they
  165. are posted to the net.
  166.  
  167. The rules are posted to the following Usenet news groups:
  168.  
  169.     comp.unix.wizards
  170.     comp.lang.c        
  171.  
  172. As of 1988, the winners were posted to the following Usenet news groups:
  173.  
  174.     comp.sources.unix        
  175.     comp.lang.c        
  176.     alt.sources    
  177.  
  178. People are strongly encouraged to wait until the new contest rules
  179. have been posted before sending entries.  The rules, and sometimes
  180. the contest Email address itself, change from time to time.
  181. The typical start date for a contest is March 15.  The typical
  182. end date for a contest is May 20.
  183.  
  184. Last, PLEASE don't code in the style of these programs (unless you
  185. are submitting a contest entry of course!)  It is hoped that you will
  186. gain an understanding that bad style destroys an otherwise correct
  187. program.  Real programmers don't write obfuscated programs that other
  188. people have to use!
  189.  
  190. Happy pondering,
  191.  
  192.     Landon Curt Noll   (chongo@uts.amdahl.com)
  193.     Larry Bassel       (lab@sun.com)
  194.